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A METHOD AND SYSTEM FOR IDENTIFICATION AND PRESENTATION OF 
STATISTICAL USAGE DATA FOR MESSAGING SYSTEMS 

FIELD OF THE INVENTION 

The present invention relates generally to electronic communications systems and, in 
5 particular, to messaging systems used in a networked computing environment. 

BACKGROUND OF THE INVENTION 

Instant messaging systems provide an alternative to traditional communication systems, 
such as the telephone and fax machine. These messaging systems have assumed an important 
role in business and personal communication, and continue to gain popularity. 

10 An instant messaging system allows people to communicate in real time through 

computers connected in a network. Usually an instant messaging system allows users to 
exchange electronic text messages. A first user types a message on a keyboard connected to that 
first user's computer and that message is immediately sent to and displayed as text on a second 
user's computer. The second user can respond, if desired or needed, by typing a new message. 

15 That new message is then sent back to and displayed as text on the first user's computer. By 
repeating this process, the first and second user can carry on a typed conversation over the 
network. 

Each user in an instant messaging system is usually identified by a unique number or 
address. Typical messaging systems also include a means for indicating when a particular user is 
20 signed into the messaging system and available for an online messaging session. A common 
indicator is an icon appearing on other users' displays that provide a potential recipient's name 
and/or address. A user can establish a two-way communication link by sending a message to any 
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other user that the system indicates is online. Users usually have some control over which users 
can view their online status, and which users' status they want to see displayed on their own 
computer. Access control usually takes the form of an address list. An address list comprises 
entries corresponding to other users of the messaging system. Each entry typically contains 
5 information about the other user's identity and/or address and whether or not that user's online 
status is of interest to the owner of the address list. The address list is, of course, as much for 
security as for convenience. An address list allows a user to filter out unwanted information 
about other users. An address list also allows a user to limit unwanted monitoring by other users. 
Many instant messaging systems also allow more than two people to engage in a single 

10 messaging session. An example of a comprehensive messaging system is disclosed in United 
States Patent 6,484,196 (the '196 patent) entitled "Internet Messaging System and Method for 
Use in Computer Networks." 

But current instant messaging systems do not address the problem of predictive timing. 
The problem of predictive timing refers to the need of a first user to know when a second user 

15 will be available for contact via a given communications method. Users generally have no way 
of knowing when other users will be online and available for an instant messaging session unless 
they make arrangements in advance. A lack of predictive timing among users reduces an instant 
messaging system's reliability, and users often waste time and effort attempting to make initial 
contact with other users. Thus, the ability to monitor a particular user's usage patterns and 

20 determine when that particular user is most likely to be online would make instant messaging 
systems more reliable and less time consuming. United States Patent 6,519,639 (the '639 patent) 
discloses a method of monitoring a user's activity in a messaging session, but it does not teach a 
method of monitoring the aggregate usage patterns that are needed in order to provide 
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predictability. Therefore, a need exists in the art for a system and method of monitoring a user's 
aggregate usage patterns and using those patterns to predict when the user is most likely to be 
online and available for a messaging session. 

SUMMARY OF THE INVENTION 

5 The present invention comprises a predictive timing system (PTS) that facilitates 

communication through a messaging system by identifying times when a user of the system is 
most likely to be available for a messaging session. The PTS comprises an event monitor (EM), 
a usage database (UDB), a usage processor (UP), and a usage indicator (UI). 

The EM continuously monitors activity on the messaging system. The EM records event 

10 data in the UDB as events are detected. The UDB functions as a central repository for PTS data. 
The EM could be configured to record every event that occurs on the messaging system, but 
could also be configured to compare each event with a watch list. A watch list would allow 
users (or an administrator) to filter the amount of data collected by limiting the recording to 
particular types of events included in the watch list. The data collected could be very generic, 

15 such as the time of day that a user signs into the messaging system and the length of time that the 
user was signed in. But data could also be much more specific and include such information as 
the number of messages sent or received during a particular time frame. Other types of event 
data will be obvious to a person of ordinary skill in the art, and the examples just given are only 
intended to be illustrative and not limiting. 

20 The UP retrieves event data from the UDB and compiles statistical data models that 

reflect a user's usage patterns. A typical set of data models might include the number of hours 
per day that a user spent online framed in time blocks of consecutive online hours, or the number 
of consecutive hours spent online within specific time frames such as business hours or 
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weekends. Again, this list is intended to be illustrative and not limiting. The number and types 
of data models that could be prepared are virtually unlimited and could easily be tailored to meet 
any need. 

Finally, the usage indicator would present these statistical data models as a summary 
usage report to the end user. Typically, the usage report would be presented in the form of a 
chart or table that allow the end user to readily determine the best time to contact another user for 
an online messaging session. 

BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 is a depiction of a typical networked computing environment in which the present 
invention could be implemented. 

FIG. 2 represents the memory configuration of a typical computing workstation using the 
present invention; and 

FIG. 3 is a functional block diagram illustrating the operation of the event monitor. 

FIG. 4 is an example of the contents of a usage database recorded by the event monitor. 

FIG. 5 is a functional block diagram illustrating the operation of the usage processor and 
usage indicator to prepare and display statistical data to the end user. 

FIG. 6 is an example of the contents of a typical address list with access properties. 

FIG. 7 depicts the type of statistical data that usage processor could produce. 

FIG. 8 is an example of a usage report that usage indicator could produce. 

FIG. 9 is another example of a usage report that usage indicator could produce. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

As used herein, the term "access list" means any mechanism that enables an individual 
messaging system user to exercise control over the accessing and viewing of their usage data by 
other messaging system users. 
5 The term "database" means any collection of data stored together and organized for rapid 

search and retrieval, including without limitation flat file databases, fielded databases, full-text 
databases, object-oriented databases, and relational databases. 

The term "messaging system" refers to any means of transmitting an electronic message 
from one user to another. 

10 The term "record" means any action that causes information to be saved in a temporary 

or persistent storage medium. 

The term "system event" means any occurrence that is significant to a messaging system 
or a significant point in time when a unique system process occurs within a messaging system. 

The term "watch list" refers to any mechanism that enables a messaging system user or 
15 administrator to identify types of messaging system events to be recorded when detected. 

In the preferred embodiment of the PTS, the EM, UP, and UI are all implemented as 
computer instructions. But a person of ordinary skill in the art will appreciate that EM, UP, and 
UI components could be configured in many different ways. For example, the EM, UP, and UI 
components may operate independently of each other, or they may be integrated into a single 
20 computer program. Similarly, each component may operate independently or be integrated into 
an existing messaging system. Moreover, each component may be implemented as either a 
hardware component or a software component, or any combination of the two. 
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The present invention operates in conjunction with a messaging system. The discussion 
below is presented in the general context of an instant messaging system implemented across a 
computer network, but a person of ordinary skill in the art will appreciate that the invention is 
also applicable to other types of messaging systems, including email and electronic bulletin 
5 board systems. 

Furthermore, a user interacts with the PTS through a graphical user interface (GUI). A 
person of ordinary skill in the art will be familiar with the various types of GUIs commonly used, 
including graphical window systems, and they need not be described in greater detail herein. 
The foregoing and other objects, features, and advantages of the invention will be apparent from 
10 the following more particular description of the preferred embodiment of the invention, as 
illustrated in the accompanying drawings wherein like reference numbers represent like parts of 
the invention. 

FIG. 1 is an illustration of computer network 100 associated with the present invention. 
Computer network 100 comprises local workstation 108 electrically coupled to network 

15 connection 102. Local workstation 108 is electrically coupled to remote workstation 110 and 
remote workstation 112 via network connection 102. Local workstation 108 is also electrically 
coupled to server 104 and persistent storage 106 via network connection 102. Network 
connection 102 may be a simplified local area network (LAN) or may be a larger network such 
as a wide area network (WAN) or the Internet. Furthermore, computer network 100 depicted in 

20 FIG. 1 is intended as a representation of a possible operating network that may contain the 
present invention and is not meant as an architectural limitation. 

The internal configuration of a computer, including connection and orientation of the 
processor, memory, and input/output devices, is well known in the art. The present invention is a 
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methodology that can be embodied in a computer program. Referring to FIG. 2, the 
methodology of the present invention is implemented in conjunction with messaging system 220. 
Messaging system 220 enables two-way communication between users of local workstation 108, 
remote workstation 110, and remote workstation 112 over network connection 102. The 
5 components of the present invention comprise EM 230, UP 240, and UI 250, all of which reside 
in memory 200. Messaging system 220, EM 230, UP 240, and UI 250 described herein can be 
stored within memory 200 of any workstation or server depicted in FIG. 1. Alternatively, 
messaging system 220, EM 230, UP 240, and UI 250 can be stored in an external storage device 
such as persistent storage 106, or a removable disk such as a CD-ROM (not pictured). The 

10 present invention further comprises UDB 360 (see FIG. 3) that could also be stored in memory 
200 or an external storage device such as persistent storage 106, or a removable disk such as a 
CD-ROM. Memory 200 is only illustrative of memory within one of the machines depicted in 
FIG. 1 and is not meant as a limitation. Memory 200 also contains processor data 210. The 
present invention may interface with processor data 210 through memory 200. 

15 In alternative embodiments, messaging system 220, EM 230, UP 240, and/or UI 250 can 

be stored in the memory of other computers. Storing messaging system 220, EM 230, UP 240, 
and/or UI 250 in the memory of other computers allows the processor workload to be distributed 
across a plurality of processors instead of a single processor. Further configurations of 
messaging system 220, EM 230, UP 240, and UI 250 across various multiple memories and 

20 processors are known by persons skilled in the art. 

FIG. 3 provides a functional block diagram illustrating the operation of EM 230. In the 
preferred embodiment, both messaging system 220 and EM 230 are in continuous operation. 
Thus, once EM 230 starts (300) it constantly monitors messaging system 220 for system events 
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(310). System events include, for example, such things as a user signing in or out of the 
messaging system, or a message being sent or received. When EM 230 detects a system event, 
EM 230 identifies the user (320) that caused the system event. Although not required, the 
preferred embodiment allows each user of messaging system 220 to disable the collection of 
5 their own usage data. Thus, EM 230 must determine whether the user that has been identified 
allows usage data collection (330). If not, EM 230 simply starts over and waits for the next 
system event (310). But if usage data collection is appropriate, EM 230 determines if the type of 
system event is contained in watch list 345 (340). Watch list 345 could exist in various forms, 
such as a separate text file that is read by EM 230, or it could reside in database 360. Persons 

10 with skill in the art will appreciate the many forms that watch list 345 could assume and these 
forms need not be described in greater detail herein. Finally, if user collection is enabled and the 
system event is included in watch list 345, EM 230 records system event data (350) in UDB 360. 
EM 230 then waits for the next system event and repeats this cycle. 

FIG. 4 illustrates the type of data that EM 230 might collect and record in UDB 360. In 

15 FIG. 4 each column heading in the first row represents a typical field name that could be used in 
UDB 360. Each row in FIG. 4 represents a system event record. Thus, in the example, UDB 
360 indicates that the user identified by the unique address 'aP signed on to the messaging 
system at 8:00 a.m. on the morning of January 1, 2001 (record no. 2). Records no. 3 and 4 
indicate that user 'bill' signed on nine minutes later and sent an instant message to 'aP at 8:12 

20 a.m. User 'aP received the message from 'bill' almost immediately, at 8:13 a.m., according to 
record no. 5. Record no. 6 indicates that a third user, 'charlie,' signed on at 9:00 a.m. Finally, 
record no. 7 indicates that 'bill' signed off at 10:30. This example is intended to be illustrative 
only, and not limiting the scope of the invention in any way. A typical database would likely 
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contain thousands, or even millions, of records and could contain much more detailed data. 
Furthermore, a typical database would continue to grow with continued use of the messaging 
system. The discussion that follows demonstrates how the data illustrated in FIG. 4 would be 
used in a typical implementation of the PTS. 
5 FIG. 5 is a functional block diagram illustrating the operation of the UP 240 and UI 250 

to prepare and display statistical data to the end user. The process starts (400) when a first user 
of messaging system 220 makes a request for usage report on a second user. In the preferred 
embodiment, the first user would make this request by selecting the appropriate menu command 
or clicking a command button in the graphical user interface. Although not required, the 

10 preferred embodiment allows every user to restrict access to their own usage data to certain other 
users of messaging system 220. Each user of messaging system 220 would have an individual 
access list 430 that only they or an administrator could modify. Access list 430 would contain an 
entry granting or denying access to other particular users, or even groups of users. Access list 
430 could have many forms, including that of a simple text file. Access list 430 could also be 

15 integrated with a user's address list. An illustration of second user's address list with access 
properties is provided in FIG. 6. Persons with skill in the art will appreciate the many forms that 
access list 430 could assume and these forms need not be described in greater detail herein. 
Thus, after a first user makes a request for a usage report (420) on a second user, second user's 
access list 430 is checked for appropriate authorization. Referring to the example in FIG. 6, if 

20 first user is 'al' then access to second user's usage data would be granted. If, however, first user 
was 'charlie' access to second user's usage data would be denied. If access is appropriate, UP 
240 then retrieves second user's usage data (440) from UDB 360 and compiles statistics on 
second user's activity (450). A typical set of statistics might include the average time that 
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second user signs on to messaging system 220 each day, or the number of messages received and 
responded to during any given time frame. FIG. 7 is an example of a set of statistics that could 
be collected for second user. The example data in FIG. 7 represents the data that UP 240 might 
collect about user 'aP (whose real name is Albert). UI 250 then uses the compiled statistics to 
5 prepare a summary usage report and displays it on first user's computer (460). FIG. 8 and FIG. 9 
illustrate the type of summary usage report that UI 250 might produce based upon the example 
statistics provided in FIG. 7. First user then may optionally save the usage report (470) as a 
separate summary file 480. Otherwise the process ends (490). 

It will be understood from the foregoing that various modifications and changes may be 
10 made in the preferred embodiment of the present invention by those skilled in the art without 
departing from its true spirit. It is intended that this description and the examples provided are 
for illustrative purposes only and should not be construed in a limiting sense. The scope of the 
invention should be limited only by the language of the following claims. 
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